1. Field of the Invention
The present invention relates to graphical systems for creating and executing data flow programs, and more specifically to method and apparatus for improved local and global variable capabilities in a graphical data flow programming environment
2. Description of the Related Art
A computer system can be envisioned as having a number of levels of complexity. Referring now to FIG. 1, the lowest level of a computer system may be referred to as the digital logic level. The digital logic level comprises the computer's true hardware, primarily consisting of gates which are integrated together to form various integrated circuits. Other hardware devices include printed circuit boards, the power supply, memory, and the various input/output devices, among others. Gates are digital elements having one or more digital inputs, signals representing 0 or 1 states, and which compute an output based on these inputs according to a simple function. Common examples of gates are AND gates, OR gates, etc. It is also noted that there is yet another level below level 0 which can be referred to as the device level. This level deals with the individual transistors and semiconductor physics necessary to construct the gates comprising the digital logic level.
The next level, referred to as level 1, is referred to as the microprogramming level. The microprogramming level is essentially a hybrid between computer hardware and software. The microprogramming level is typically implemented by software instructions stored in ROM (read only memory), these instructions being referred to as microcode. The microprogramming level can be thought of as including various interpreters comprised of sequences of microcode which carry out instructions available at the machine language level, which is at level 2. For example, when an instruction such as an arithmetic or shift function appears at the machine language level, this instruction is carried out one step at a time by an interpreter at the microprogramming level. Because the architecture of the microprogramming level is defined by hardware, it is a very difficult level in which to program. Timing considerations are frequently very important in programming at this level and thus usually only very skilled, experienced microprogrammers operate at this level.
As mentioned above, the level above the microprogramming level is referred to as the machine language level. The machine language level comprises the 1's and 0's that a program uses to execute instructions and manipulate data. The next level above the machine language level is referred to as the assembly language level. This level includes the instruction set of the computer system, i.e. the various op codes, instruction formats, etc. that cause the computer to execute instructions. In assembly language each instruction produces exactly one machine language instruction. Thus, there is a one to one correspondence between assembly language instructions and machine language instructions. The primary difference is that assembly language uses very symbolic human-readable names and addresses instead of binary ones to allow easier programming. For example, where a machine language instruction might include the sequence "101101," the assembly language equivalent might be "ADD." Therefore, assembly language is typically the lowest level language used by programmers, and assembly language programming requires a skilled and experienced programmer.
The next level includes high level text-based programming languages which are typically used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to in this disclosure as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. For example, text-based programming environments have traditionally used a number of programs to accomplish a given task. Each program in turn often comprises one or more subroutines. Software systems typically coordinate activity between multiple programs, and each program typically coordinates activity between multiple subroutines. However, in a text-based environment, techniques for coordinating multiple programs generally differ from techniques for coordinating multiple subroutines. Furthermore, since programs ordinarily can stand alone while subroutines usually cannot in a text-based environment, techniques for linking programs to a software system generally differ from techniques for linking subroutines to a program. Complexities such as these often make it difficult for a user who is not a specialist in computer programming to efficiently program a computer system in a text-based environment.
The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. For example, a computer programmer typically develops a conceptual model for a physical system which can be partitioned into functional blocks, each of which corresponds to actual systems or subsystems. Computer systems, however, ordinarily do not actually compute in accordance with such conceptualized functional blocks. Instead, they often utilize calls to various subroutines and the retrieval of data from different memory storage locations to implement a procedure which could be conceptualized by a user in terms of a functional block. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
One particular field in which computer systems are employed to model physical systems is the field of instrumentation. An instrument is a device which collects information from an environment and displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others. An instrumentation system ordinarily controls its constituent instruments from which it acquires data which it analyzes, stores and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use.
In the past, many instrumentation systems comprised individual instruments physically interconnected. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone. An incremental improvement in the manner in which a user interfaced with various instruments was made with the introduction of centralized control panels. In these improved systems, individual instruments were wired to a control panel, and the individual knobs, indicators or switches of each front panel were either preset or were selected to be presented on a common front panel.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems the user interacted with a software program executing on the computer system through the video monitor rather than through a manually operated front panel. These earlier improved instrumentation systems provided significant performance efficiencies over earlier systems for linking and controlling test instruments.
However, these improved instrumentation systems had significant drawbacks. For example, due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it was often necessary for a user to develop a program to control the new instrumentation system desired. As discussed above, computer programs used to control such improved instrumentation systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of instrumentation systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation data. Thus, development and maintenance of the software elements in these instrumentation systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. Referring now to FIG. 1A, a graphically based programming environment can be represented at level 5 above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. As the user constructs the data flow diagram using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a text-based computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems and modeling processes as well as for any type of general programming.
In the method described in Kodosky et al, no methodology was provided to allow a user to implement a local variable that can only be accessed by a particular diagram or VI and which cannot be affected by VIs not in that diagram. However, it would be highly desirable to have a local variable capability in a graphical programming environment for several reasons. First of all, as is well known to programmers in traditional text-based programming environments, local variables enable a user to ensure that the variable used in a particular subroutine or module will not be affected by the same variable used in other subroutines in other modules. This provides a safer and cleaner programming interface. For example, in a large program where only global variables are allowed, the user may not be able to keep track of the order in which that global variable is updated, and different modules may affect the global variable in undesirable ways. However, with a local variable which is local to a particular subroutine, the user can guarantee that only that subroutine will use that local variable and hence the variable will not be affected by calls or operations in other subroutines.
In addition, the system and method described in Kodosky et al included only one icon on a block diagram where a user could change or read a value in a control. In other words, no two controls could occupy the same storage location, i.e., a user could not create a control representing a storage location and then place subsequent copies of that icon in other places in the block diagram. Since multiple locations could not be created, there was no problem with these locations being updated in an undetermined order. However, this limited program flexibility and was hence undesirable because a user could only update the input to a control at one place in a block diagram, i.e., the input to a control could not be updated in multiple places concurrently in a block diagram. For example, if a program had two loops running and it was desired to stop them with only one button, in the method described in Kodosky et al this could only be accomplished using a global variable hooked to the button with both loops reading from the global. The use of a global variable in this situation is undesirable due to the problems mentioned above.
Also, controls and indicators which could be created by a user in Kodosky et al. could be either read from or written to by a user, but not both. Input terminals associated with controls were read only and output terminals associated with indicators were write only. Thus, a control was either read only or write only, but not both. One advantage of using read only input terminals and write only output terminals was that race conditions could not occur, i.e. race conditions cannot occur in a data flow program between a read only control and a write only indicator. However, providing only read only or only write only controls greatly limits the flexibility of the program. It would be highly desirable to allow a user to read from or write to any control or indicator at any point in a diagram at any time.
Therefore, a method and apparatus is desired which provides a local variable capability for controls and indicators to allow a user to read and write the memory associated with controls and indicators in multiple places in a block diagram.
In the system and method described in Kodosky et al., an iterative loop function and an indefinite loop function were included to allow a user to perform iterations on data. These loop functions included shift registers which provided these loops with the capability of storing data from one iteration to the next in order for them to operate on previous data or to enable them to remember what had occurred in a previous iteration. Shift registers for storage of values could be initialized upon entering a loop, i.e., assigned values upon entering the loop, and then could be updated subsequently during execution of the loop. The loop could change these variables a multitude of times depending on the desired result. Also, the shift registers could be left uninitialized, i.e., not assigned values when the loop was entered. The use of shift registers in loops can be best illustrated by the Fibonacci number problem which is described in U.S. Pat. No. 4,901,221. In the case where the shift registers are not initialized, the values in the shift registers on entering the loop are the same as the values written to the shift registers the previous time the loop was executed. In this manner, a shift register that is not initialized on entry in a loop could essentially be used as a global variable because it "remembers" what happened on previous updates.
Therefore, by creating a subVI having a loop wherein the shift register is not initialized upon entering the loop, the shift register essentially behaved as storage for a global variable. By placing this subVI wherever desired, the user essentially could place global variables wherever desired in a VI. This was very common practice in order to use global variables. However, one problem with this method of creating a global variable was the associated storage and execution overhead. This was because a loop structure contained within a subVI had to be created in order to merely update a global variable. The creation of a loop structure and its associated subVI require some amount of code. Also, if a global variable was required to be updated, a function call to a subVI which in turn executed a loop was performed merely to update the global variable. This resulted in a certain amount of execution overhead, i.e., a much greater amount of work than should be necessary to simply update a global variable.
Therefore, a system and method is desired which allows a new form of global variable to be used in a graphical data flow environment with a reduced amount of execution and storage overhead.